エンジニアがやらなくても良いけど非エンジニアにはちょっと難しいことを非エンジニアが簡単確実にできるようにした話
2024.07.072024/07/05 に DevelopersIO 2024 SAPPORO Business Lab が札幌で開催されました。
そのパネルセッションで話題になった、コスト削減と人材確保の課題に対するアプローチのひとつになるかなと思いましたので参考にしていただけましたら幸いです。
エンジニアがやらなくても良いけど非エンジニアにはちょっと難しいことを非エンジニアが簡単確実にできるようにした話
クラスメソッドではグループ企業含めて共通に利用する情報システムについては、専任のチームが管理を行ってくれています。しかし、各部門の業務によって個別に必要となるものについては各部門で管理を行なっています。
私が所属する小売流通ソリューション部では、サービスの開発や運用に伴いさまざまな SaaS を部門独自に利用しています。また、サービス提供のための AWS アカウントも数多く管理しています。
これらの管理業務をエンジニアたちが本来の業務の片手間で行うのはパフォーマンスの低下や管理漏れなど、組織として好ましくない状態になりがちです。
そのため 2020年頃から部門内に専属の情シスチームを立ち上げようと言う流れになり、翌 2021年から本格的に動き始めました。
1年間試行錯誤しながら仕組みやツールを整備し、Cloud9 を利用して非エンジニアが簡単な操作で複数の AWS アカウントから SecurityGroup の一覧を一括取得できる仕組みを作成したことを 2022年にブログ記事で紹介しました。
当初は、SecurityGroup の一覧は上記記事で紹介した Amazon WorkSpaces で用意した Windows 環境を利用していました。
また IAM User や IAM Policy の変更および作成削除のログを確認するために、50以上ある対象 AWS アカウントへスイッチロールしては Athena コンソールでクエリを実行して結果の csv ファイルを取得していました。
これはさすがに手間と時間がかかりすぎる非効率な作業でしたので、部内エンジニアメンバーにも協力してもらい少しずつ Cloud9 上で自動処理が行える環境作りを進めました。
結果、手作業で数日がかりだったものが準備と Cloud9 の操作を数分行えば Slack に通知が届くまで放置して待つだけになりました。
その後は Cloud9 を利用した仕組みに対して少しずつ改良を重ね、自動処理を増やしさらなる作業時間の短縮を実現していますが、同時に非エンジニアが簡単確実に実施できるようちょっとした工夫を加えています。
極限まで Linux コマンドの入力や複雑な操作をしないで済むようにした
処理を行うスクリプト群のソースコード自体は GitHub リポジトリで管理しているため、作業実施時にはどうしても git clone コマンドを Cloud9 上で実行して最新の情報を取得する必要がありますが、作業手順書からコピペしてもらえば済むようにしています。
作業実施時は、Cloud9 コンソール左側のファイルツリーから特定のファイルを右クリック、展開されるメニューから「RUN」を選択するのみで済むようにしています。
それ以降の操作は、対話式メニューに表示される数字と、作業用 IAM User の MFA コードの入力のみで、結果の取得や git push といった処理は自動で行われる仕組みとしました。
SecurityGroup 一覧、IAM User や IAM Policy の変更や作成削除のログ取得、IAM 関連リソース一覧、Route53 に登録されたレコードの情報一覧などの取得も行いますが、これらのスクリプトはそれぞれ別のディレクトリに配置されています。
そのため都度フォルダツリーを展開し、目的の実行ファイルを探して実行する方法だとファイルツリーが展開されすぎてわかりにくく、間違いやすくなっていました。この対話式メニューの実装により操作がシンプルになったため情シスメンバーに喜んでもらえました。
Slack 通知と Cloud9 コンソールに表示される実行結果のメッセージをできるだけわかりやすくした
処理によっては数十分待たないと終わらないものもあるため、作業者が Cloud9 コンソールに張り付く必要のないよう、処理が完了したら次に行う作業内容を添えて Slack に通知するようにしました。同時に、Cloud9 コンソールにも次に何をすべきかが明確になるようメッセージを表示するようにしました。
処理によって、出力されたファイルを Google Drive に保存するもの、GitHub リポジトリで差分を確認して Pull Request を作成するものなどがあり、作業手順書と Cloud9 コンソールを行ったり来たりしないで済むようにしたかったためです。
これにより、新規メンバーなど作業経験が少ない人が作業実施者の場合でも、次にすべき作業を正しく把握してもらえるようになり、作業手順の読み飛ばしなどによる作業ミスの低減に繋がったと思っています。
実行ログに細かく情報を出力させるようにした
可能な限り詳細なログを残すのは当たり前ではありますが、社内利用前提のスクリプト群ですのでエラー処理の実装にはあまり工数をかけませんでした。その代わりに、処理が失敗した時はログの情報から失敗したコマンド等が発見しやすくなるよう、できるだけ細かく処理のステップごとにログを出力させるようにしました。
これにより、非エンジニアでも作業経験が増えてきたメンバーはどの処理が失敗していたのか、何が問題だったのかを自身で確認することができるようになり、復旧やリトライ、エンジニアへのエスカレーションなどの判断がスムーズに行えるようになりました。なお、エンジニアへのエスカレーションはほとんど発生していません。
上記のような自動化とは別に、エンジニアがやらなくても良い業務を洗い出しては非エンジニアが実施できるような仕組みづくりも続けてきました。
およそ4年でどうなったか
チーム立ち上げから 4年ほどの期間を経た現在では次のようなことを全て、非エンジニアで構成された情シスチームが自律的に実施できる状態になっています。
アカウント管理業務
- 部門で独自に利用している SaaS 類や メーリングリスト（ML）、AWS アカウントなどの管理業務
- 情シスチームが部門の窓口となって SaaS のアカウント対応や社内他部門との連携を行うことで、いつ誰が何を利用開始/終了したか、どのような権限かなどの情報を集約することで、退職 / 異動時の削除漏れ（に伴う情報漏洩事故と無駄な費用の発生）を防ぐ
- チケットに承認の証跡と対応記録等を残し、対応途中で忘れられてしまうことを防ぎ、経緯を追えるようにする
- 例）個人で手配したが、 不要になったアカウント等の削除忘れ
- 新規に部門独自で利用したい SaaS のサプライヤーチェックおよび全社ワークフローによる利用申請の代行
- チーム単位等での利用の乱立や全社規定（サプライヤーチェックと利用申請）の対応漏れ、利用終了時の放置などを防ぐ
- 仕組み/仕様上の理由で止むを得ず作成した共有アカウントの定期パスワード変更作業
これら業務は Jira Service Management（JSM）を利用したワークフローとチケットで管理しています。
AWS 環境のリソースチェック業務
情シスチームでリソースそのものの管理は行わないのですが、一定期間ごとにその時点での情報を取得し、前回と差分がある場合に問題がないのかを各プロダクト担当者に確認を依頼する。ということをしていただいています。
各情報は基本的に Cloud9 環境から describe コマンド等を自動実行して取得、GitHub へ push して差分と変更の記録を残していますが、一部は部門内共有用 Google Drive の所定のフォルダに保存しています。
- IAM User の作成削除変更ログ
- IAM User Group Role
- SecurityGroup 設定
- Route53 設定
- IAM Policy 作成削除変更ログ
各種台帳管理業務
アカウント管理および AWS 環境のリソースチェックなどの業務に付随する形で、各種情報を記録管理する台帳類の管理
- AWS アカウント
- AWS リソース
- 部内利用 SaaS 一覧およびユーザーとその権限
- お客様組織が管理している SaaS に参加している部内のメンバー
- etc...
これら台帳類の多くはもともとスプレッドシートで管理していましたが、情シスチームメンバーが自ら Google AppSheet や GAS などを利用して自動化や効率化といった継続的な改善活動を行なってくださっています。
現在私は、小売流通ソリューション部で SRE チームの一員として情シスチームの支援を中心に部内のさまざまな業務改善に関わっていますが、情シスチームのメンバーが自主的に業務効率化や仕組みづくりにも取り組み始めてくれているので、今後は徐々に支援の比率を減らして部内全体のセキュリティ強化やコスト削減などの改善に取り組んでいきたいと考えています。
情シスチームの皆さん、いつも本当にありがとうございます。これからもよろしくお願いします！
